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Telecommunications network resource handler 
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TECHNICAL FIELD 

The present invention relates to a resource handler for use in an 
operational support structure for managing a telecommunications 
network, comprising a service and resource database containing 

10 information regarding network resources. The invention also 
relates to a method of structuring information in a resource 
handler database for use in such an operational support structure. 
Also, the invention relates to a use of a resource handler for a 
service type handler in an operational support structure for a 

15 telecommunications network, for creating and maintaining service 
type recipes and their relations. 

STATE OF THE ART 

Resource management in operation support systems for tele- 
20 communication is difficult due to the size and complexity of these 
types of networks. A telecommunication network normally changes 
constantly as new resources/services are added, and as old 
superfluous resources/ services are removed or replaced. Often, a 
lack of information regarding available/redundant resources lead 
25 to stove-pipe solutions for particular services or networks with 
high levels of duplication. The lack of up-to-date information and 
the resulting duplication lead to higher management costs for the 
network operator. Sometimes resource investments are unnecessary 
because redundant resources may actually be available. There may 
; 30 be resources that supposedly are engaged by old services that are 
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no longer active or have been replaced by new services that use 
other resources . 

An operational support structure for a telecommunications network 
5 is for example described in US 5,640,505. This support structure 
is divided into a set of domains each of which provides a 
particular management function for the network. This document 
teaches a general support structure but it provides very little 
details for implementing such a structure. Thus, there is no 
10 definite solution to the problem of how to handle network 
resources so that duplication is avoided. 

Ideally, the service and resource database should be able to 
represent all existing and all future types of telecommunication 
15 equipment and network topologies in a simple data model in order 
to be able to manage the resources of an arbitrary network. 

SUMMARY OF THE INVENTION 

According to a first aspect of this invention, there is provided a 

2 0 resource handler for use in an operational support structure for 

managing a telecommunications network, comprising a service and 
resource database containing information regarding network 
resources. The database is structured so that each resource in the 
network has a time of existence as well as a place in a hierarchy 
25 of parent/child (s) relations. The resource is defined by the 
following data: 

a point identifier that has characteristics associated to 
it, in the form of an abstract description of its capabilities; 

an abstraction of the common network element in the sense of 

3 0 a group of points that are considered to belong together; and 

a connection which is defined by two connected points. 
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Preferably, the point identifier also has characteristics 
associated to it, in the form of a list of label/value pairs. 

5 According to one advantageous embodiment of the invention, the 
element acts as a container for points, with the implicit 
characteristic that points on elements are possible to cross- 
connect . 

10 The database may be structured so as to model a topological view, 
i.e. how the resources are connected together. It may also be 
structured so as to model a time view, i.e. when the resources 
exist . 

15 The database may be structured so as to model a hierarchic view, 
i.e. how the resources are related in parent/child relationships. 
It may also be structured so as to model a characteristic view, 
i.e. by means of a list of characteristics of each resource. Also, 
the database is structured so as to model a usage view, i.e. which 

2 0 resources are combined to form a complete service instance and the 
time when that service instance exists. 

Preferably, the topological view, the time view, the hierarchic 
view, the characteristic view and the usage view are integrated in 

2 5 a data model for enabling control of each resource and the use of 

it in service instances. 

According to a second aspect of this invention, there is provided 
a method of structuring information in a resource handler database 

3 0 for use in an operational support structure for managing a 

telecommunications network, comprising the steps of allocating 



each resource in the network a time of existence as well as a 
place in a hierarchy of parent/child (s) relations, and 
defining each resource by the following data: 

a point identifier that has characteristics associated to 
it, in the form of an abstract description of its capabilities ; 

an abstraction of the common network element in the sense of 
a group of points that are considered to belong together; and 

a connection which is defined by two connected points. 

According to a third aspect of this invention, there is provided a 
use of a resource handler for a service type handler in an 
operational support structure for a telecommunications network, 
for creating and maintaining service type recipes and their 
relations . 

Preferably, the service type recipes provides a framework for 
service types, operations on service types, parameters on service 
types, hierarchical relations between service types, hierarchical 
parameter relationship, and translation of service types and 
associated parameters values into resource requirements and 
service type requirements. 

The service type handler may be used for selecting between 
different types of required services, different types of required 
resources and different service instances. 



Advantageously, the selected resources requirements are 
transferred to a resource handler that does the actual resource 
allocation. 



BRIEF DESCRIPTION OF THE DRAWINGS 

The invention will in the following be further described in a non- 
limiting way with reference to the accompanying drawings in which: 
FIG. 1 schematically illustrates the relationship between the 
5 concepts of product instance/ type and resource 

instance/ type , 

FIG. 2 schematically illustrates the relationship between 

elements, points and connections, 
FIG. 3 shows the system environment of the service and 
10 resource database of the service configuration, 

FIG. 4 is a block diagram which illustrates the relational 

structure of a service and resource database, and 
FIG. 5 illustrates the table relations and product type 

definitions . 

15 

DETAILED DESCRIPTION OF THE INVENTION 

As there are many aspects of a telecommunications system, a 
structure of the information has to be made into parts for 
interaction between product types and product instances. For 

2 0 example, it is possible to have one part of the system handling 
product types and their translation to product instances and/or 
references to resources, a second part for binding information 
about product types and product type pricing, a third part for the 
product instances and a fourth part for keeping track of all 

2 5 procedural code for data manipulation. 



This basic modeling idea is illustrated in FIG. 1, and it 
comprises four basic areas (domains) , the product type, the 
product instance, the resource type and the resource instance. The 
3 0 type areas are to be seen as where the drawings and design 
specifications are placed and the instance areas are where the raw 



. , nd the ready products are located. Thus, it « very 
™ aterial ^ ^ „ . cl L distinction between the type o£ a 
important to make ^ as between a 
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resource type and a resource instance. 

5 defined by name, parameters, revision level 
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an d behav.or. Thus ^ product type 
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The resource type is the identity of an abstract description cf 
the resource needed to implement a product type. Product types 
having children may have references to resource types. Produce 
types having no children must have references to resource types. 

5 

The resource instance is the actual instantiation of a resource 
type. Product instances having children may have references to 
resource instances. Product instances having no children must have 
references to resource instances. 

10 

The relationship between elements, points and connections is 
illustrated in Fig. 2 which is an abstract graphic view of a 
telecommunication network. Each of the squares in Fig. 2 
represents an element 10, the dots are points 11 and the fat lines 
15 are connections 12. The thin lines in the lower left element are 
also connections, only scaled down in width to fit the element. 
This is represented in the Service Resource Data Base (SRDB) 
according to this invention, in the form of tables in a relational 
database . 

20 

Having an SRDB is to have a formal and abstract model for 
describing a telecommunication network, its parts, their 
capabilities, how the parts are connected, by whom and when a part 
is used and so on. What exists in SRDB are lists of elements, the 
2 5 points on these elements, the capabilities/attributes of each 
point and how the points are connected. These lists (in the form 
of database tables) are filled with information of what equipment 
exists (and when it exists) , what it can do and if it is used by 
someone . 

30 
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The point 11 is known under many names, such as port, termination 
point, external access point, binding post etc. in the real world. 
In SRDB they are abstracted to one concept, the point which in 
essence is an identifier. To distinguish between different types 
5 of points, every point must have a type that is a formal abstract 
description of its capabilities. A point type may have one or 
several capabilities. A point must always belong to an element, it 
can not exist on its own. 

10 The element 10 is in essence a group of points that are considered 
to belong together. To be an element, the points that are attached 
to it must have full connectivity to each other, i.e. any point 
must be possible to cross connect to any other point within the 
same element. This connectivity may be restrained a bit as the 

15 capability/attribute types of the points may have the requirement 
that the same capability/attribute must exist on both points in 
order to be able to cross connect. 

The connection is the very information that says that a point is 
20 connected to another point. In reality this is a pair of points. 
There are basically two kinds of connections, the infrastructure 
connection, i.e. a wire, and a cross connect, which is 
controllable . 

2 5 The capability is a collection of attributes. Each attribute is in 
essence a pair consisting of the name of a parameter and the value 
of the parameter. This is the formal way to describe the 
characteristics of a point type. 
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t he entity that in itself has all the 
Th e service instance is the V ^ ^ ^ 

co^on data regarding the resources 
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SARM IS where it » , t--- t ^ ^ ^ ^ ^ „ 

30 Layer ASDL command and routed a new 

and SRDB for additiona! information which 



CSDL command is translated to an ASDL command and routed -o the 
NEP 15. The response from the NEP follows in principle the same 
way backwards, where return status and data is used to updare SRDB 
16. 

The creation of a DuoCom instance is now used as an example of how 
to use the information in the data structures. The product DuoCom 
is assumed to consist of the sub products ISDN Access, E-mail, 
Personal Home Page and 02 0 -connection. These five products, 
together with all relevant parameters, parameter values, resource 
definitions, location of resources, product information, product 
type cost, revision levels etc. and the associated provisioning 
control are considered to be entered in the product type data 
structure . 

Step zero is that an initiator, probably a customer care system 
(at some convenient time) has got access to an Operator Product 
Portfolio (OPP) and knows at least the names of the available 
products. When an end user contacts the customer care system, the 
customer is given a list of product types to select from. In this 
case the DuoCom product is the interesting one, so. a request is 
made for more information about the product type. 

In step 1 the OPP, by using the product name and the fact that 
product information is wanted as parameters, looks in the product 
type information table where all aspects of information and where 
to find it is located. 

In step 2, assuming that the customer wants the product, a 
feasibility check is made to check if it is possible to implement 
the product with the existing conditions, i.e. if all 



prerequisites are fulfilled. Now a "call" for this code is made. 
As the execution starts, this code uses the product type is input 
to look in the Product type hierarchy. By looking here it is 
possible to find out which (sub) products the DuoCom product is 
composed of. In this case the four product types ISDN Access, E- 
mail. Personal Homepage and 02 0 -connection will be found. As they 
in turn may consist of further more simple products, the Product 
type hierarchy is once again examined to see if the new products 
have sub products and so on until no more product types are found. 

As some of the (sub) products may be optional, i.e. the end 
customer has to be asked the (sub) product is desired and informed 
about the possible choices. This results in an interactive loop in 
which the customer picks the desired (sub) products . As these 
(sub) products are selected, the Product type operation parameters 
and the Product type parameter tables are examined to find out 
which parameters are needed. As this selection of (sub) products is 
dynamic to its nature, the Product type relations table is 
examined to check that combinations of incompatible product types 
are not accidentally created. When this loop has ended, the 
Product type prerequisites and the Product type resource 
prerequisites tables are examined with regard to Product instance 
data and resource data, if the sufficient amount of resources or 
existing product instances are available, so that it is possible 
to instantiate this new product instance. 

In step 3 the Product type cost and Product type hierarchy tables 
are examined to get the cost for all individual (sub) products . It 
is however left to the customer care system to interpret and 
customize this information for the customer. This price system may 
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be in an internal ana the customer care system »* 

transform this currency into a local currency. 

step 4 assuming that the feasibility showed that 
1 •>,,. the created instance order may be 

cementation was poss.ble, the crea ^ ^ 

is sued. i.e. to ta*e all ^^J^ J x ins ert one or 

" — — T "r^c cr; tables and result in a tree 
more product orders in Produce o 

<n the Product instances tables, 
of product instances in the Proauc 

, the time of delivery arrives, it is finally u P to 
in step 5, when the time ^ # . e 

r9 to activate the reserved resources, 
resource managers to activcu. 

j in a relational database, see FIG. 4 which 
All data is stored m rel ^ ^ ^ 

shows only the table names and the 

relations to/from them. The tables may be created by 
, standard text files with SQL commands. 
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, n an operational support structure 
A res ource Handler for use comprising a ^ce 

for managi n g .J^^^ — ^ g net.or, 
and resource database 
resources , 

characterized ^ ^ each resour ce in the 

that the database « structur ^ ^ niera rchy 
n etwor* has a time °r «i-t«« * s - U 

o£ parent/child <s, relations. ^ an ^ 

th at the resource i. define Y etistics ass ociated 
. point (11, ""Z'ZJZ descripti on of its capabilities: 

co it. in the for™ of an *»« „ t ,10, in the 

an abstraction of the consid ered to belong 
sense of a group of points (11, 

together, and fcy fc „ 0 oonne cted points 

a connection 
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. A resource handler ^^J^^ (11, identifier also 
characterized 1 in the form of a list of 

ha s characteristics associated to «. 
label /value pairs. 

3 . K resource handler ^ (10> acts as a 

c h a r a c t e r i . . ^ oharacter istic that 

container for pornts . possibl e to cross - connect . 

points (11) on elements (10) are p 
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4 A resource handler according to any one of claims 1 to 3 , 
characterized in that the database is structure** so 
as to model a topological view, i.e. how the resources are 
connected together. 

5 A resource handler according to any one of claims 1 to 4, 
characterized in that the database is structured so 
as to model a time view, i.e. when the resources exist. 

6 A resource handler according to any one of claims 1 to 5, 
characterized in that the database is structured so 
as to model a hierarchic view, i.e. how the resources are related 
in parent/child relationships. 

7 a resource handler according to any one of claims 1 to 6, 

c'h a r a c t e r i z e d in that the database is structured so 
as to model a characteristic view, i.e. by means of a Ust of 
characteristics of each resource. 

y A resource handler according to any one of claims 1 to 7 , 
c'h a r a c t e r i z e d in that the database is structured so 
as to model a usage view, i.e. which resources are coined to 
form a complete service instance and the time when that service 
instance exists . 

9 A resource handler according to claims 4-8, 

c'h a r a c t e r i z e d in that the topological view, the time 
view, the hierarchic view, the characteristic view and the usage 
view are integrated in a data model for enabling control of each 
, resource and the use of it in service instances. 



8 



15 



10 



15 



10 A method of structuring information in a resource r.anaxer 
database for use in an operational support structure for manage 
a telecommunications network, comprising a service and resource 
database containing information regarding network resources, ^ 
characterized in the steps of 

allocating each resource in the network a time of existence 
as well as a place in a hierarchy of parent /chi Id (s) relations, 

and 

defining each resource by the following data: 

a point (11) identifier that has characteristics assocxated 
to it, in the form of an abstract description of its capabilities; 

an abstraction of the common network element (10) m the 
sense of a group of points (11) that are considered to belong 
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together; and 
(ID 



her; and . 
a connection (12) which is defined by two connected poxnts 
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11 A method according to claim 10, 

characterized in the step of associating the point 
(11) identifier with characteristics, in the form of a list of 
label/value pairs. 

12. A method according to claim 10 or 11, 

characterized in the step of allowing the element 
UOI to act as a container for points (11), with the implicit 
characteristic that points (H) on elements (10) are possible 

cross -connect . 



13. A method according to any one of claims 10 to 12 
30 characterized 
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in the step of structuring the database 
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are 



to model a topological view, i.e. how the resources 



so as 
connected together 



14. A method according to any one of claims 10 to 13, 
characterized in the step of structuring the database 
so as to model a time view, i.e. when the resources exist. 

15 A method according to any one of claims 10 to 14, 
characterized in the step of structuring the 
database so as to model a hierarchic view, i.e. how the resources 
are related in parent /child relationships. 



16 A method according to any one of claims 10 to 15, 
characterized in the step of structuring the 

15 database so as to model a characteristic view, i.e. by means of a 

list of characteristics of each resource. 

17 A method according to any one of claims 10 to 16, 
characterized in the step of structuring the database 

20 so as to model a usage view, i.e. which resources are combined to 
form a complete service instance and the time when that service 
instance exists. 

18 A method according to claims 13-17, 
25 characterized in the step of integrating the 
topological view, the time view, the hierarchic view, the 
characteristic view and the usage view in a data model for 
enabling control of each resource and the use of it in service 
instances - 

30 
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19 A use of a resource handler according to anyone of claims 1 to 
9 for a service type handler in an operational support structure 
for a telecommunications network, for creating and maintaining 
service type recipes and their relations. 

20 A use according to claim 19, wherein the service type recipes 
provides a framework for service types, operations on service 
types, parameters on service types, hierarchical relations between 
service types, hierarchical parameter relationship, and 
translation of service types and associated parameters values into 
resource requirements and service type requirements. 

21 a use according to anyone of claims 19-20, for selecting 
between different types of required services, different types of 
required resources and different service instances. 

«-« riaim 21 wherein the selected resources 

22 A use according to claim 21, 

- »r-* transferred to a resource handler that does the 
requirements are transieneu 

actual resource allocation. 
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